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ABSTRACT 

An  attempt  Is  made  to  formulate  techniques  of  program  modification,  whereby  a 
program  that  achieves  one  result  can  be  transformed  into  a new  program  that  uses  the 
same  principles  to  achieve  a different  goal.  For  example,  a program  that  uses  the  binary 
search  paradigm  to  calculate  the  square-root  of  a number  may  be  modified  to  divide  two 
numbers  In  a similar  manner,  or  vice  versa. 

Program  debugging  Is  considered  as  a special  case  of  modification:  if  a program 
computes  wrong  results,  it  must  be  modified  to  achieve  tha  Intended  results.  The 
application  of  abstract  program  schemata  to  concrete  problems  Is  also  viewed  from  the 
perspective  of  modification  techniques. 

We  have  embedded  this  approach  in  a running  Implementation;  our  methods  are 
' Illustrated  with  several  examples  that  have  been  performed  by  it. 
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I.  INTRODUCTION 

Typically,  a programmer  directs  more  of  his  effort  at  the  modification  of  programs  that 
have  already  been  written  than  at  the  development  of  original  programs.  Even  when 
nominally  engaged  In  the  construction  of  a new  program,  he  is  constantly  recycling 
"used"  programs  and  adapting  basic  programming  principles  that  have  already  been 
incorporated  Into  other  programs. 

Much  automatic  programming  research  has  focused  on  the  origination  of  programs,  but 
very  little  of  this  work  shows  how  to  profit  from  past  experience  when  approaching  a 
new  problem.  In  this  paper,  we  wish  to  emulate  this  latter  aspect  of  programming  in  the 
context  of  an  automatic  program  development  system.  The  essence  of  our  approach  lie.s 
in  the  ability  to  formulate  an  analogy  between  two  sets  of  specifications,  those  of  a 
program  that  has  already  been  constructed  and  those  of  the  program  that  we  desire  to 
construct.  This  analogy  is  then  used  as  the  basis  for  transforming  the  existing  program 
to  meet  the  new  specifications. 

We  consider  the  debugging  process  as  an  important  special  case  of  program  modification. 
In  our  approach,  the  properties  of  an  Incorrect  program  are  compared  with  the 
specifications,  and  a modification  (correction)  sought  that  transforms  the  Incorrect 
program  into  a correct  one. 

Abstract  program  schemata  are  often  a convenient  form  for  Incorporating  programming 
knowledge;  they  may  embody  basic  techniques  and  strategies  (such  as  the 
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generate-and-test  paradigm  or  the  binary  search  technique).  The  application  of  these 
schemata  to  programming  tasks  may  also  be  considered  within  the  framework  of 
modification.  A schema  which  achieves  some  abstract  goal  is  modified  (instantiated)  to 
achieve  a concrete  goal  on  the  basis  of  a comparison  of  the  abstract  specifications  of  the 
schema  with  the  concrete  specifications  of  the  desired  program. 

The  use  of  analogy  in  problem  solving  in  general,  and  theorem  proving  in  particular,  is 
discu.ssed  by  Kling  I 1971].  The  modification  of  an  already  existing  program  to  solve  a 
somewhat  different  task  was  suggested  by  Manna  and  Waldinger  [ 1975]  as  part  of  a 
program  synthesis  system.  Also,  the  STRIPS  (Fikes,  Hart  and  Nilsson  [ 1972])  and 
HACKER  (Siissman  [ 1973])  systems  were  to  some  extent  capable  of  generalizing  and 
reusing  the  robot  plans  they  generated. 

The  next  section  elucidates  the  basic  aspects  of  our  approach  to  program  modification 
with  the  aid  of  several  relatively  straightforward  examples.  More  subtle  facets  of  the 
techniques  are  illustrated  in  the  third  section.  The  methods  described  are  amenable  to 
automation,  and  have  been  implemented  in  OLISP  (Wilber  [1976]).  All  examples  of 
modifications  that  we  present  ran  successfully  on  our  system;  a sample  run  may  be 


found  in  the  Appendix. 
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II.  OVERVIEW 

Typically,  program  specifications  are  expressed  in  a high-level  assertion  language  in 
terms  of  an  output  specification  — detailing  the  desired  relationship  between  the 
PTOgiam  variables  upon  termination,  and  an  input  specification  — defining  the  set  of 
"legal"  inputs  for  which  the  program  is  expected  to  work.  For  program  modification, 
one  is  given  a known  correct  program  with  its  input-output  specification  and  the 
specification  for  a new  program.  Comparison  of  the  two  specifications  suggests  a 
transformation  that  is  then  applied  to  the  given  program.  Even  if  the  transformed 
program  does  not  exactly  fulfill  the  specifications,  it  can  serve  as  the  basis  for 
constructing  the  desired  new  program. 


I . Basic  Technique:  Global  Transformation 

In  the  approach  to  program  modification  presented  in  this  paper,  we  stress 
transformations  in  which  all  occurrences  of  a particular  symbol  throughout  a program 
are  affected.  Such  transformations  are  termed  "global",  in  contrast  with  "local" 
transformations  which  are  applied  only  to  a particular  segment  of  a program. 

As  a simple  example,  consider  the  following  program  (annotated  with  its  output 


specification)] 
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y •-  n 

loop  until  y ' 0 

>ir.v-J]*-if  A[  P.y-l  ] < A[  2y]  then  i4[2y-J]  else  i4[2y]  fi 

y - y-J 

repeat 

assert  i4[  0]  = n7/n(/l[ /i:2;i])  . 

Given  an  array  /I[/i;2n],  wliich  is  non-empty  (r.e.,  n is  non-negative),  when  this 
program  terminates.  A[0]  will  contain  the  minimum  of  the  values  of  the  n+I  array 

elements  A[n*J] A[2n].  This  output  specification  is  formally  expressed  in 

the  final  statement: 

assert  /ItO]  - min(i4[n.2/i])  . 

To  modify  this  program  to  compute  the  maximum  of  the  array,  rather  than  the 
mipimum,  we  compare  this  specification  with  the  desired: 
assert  /1[  0 ] - max( /![  n:2n ] ) 

and  note  that  since  max{A)  • -inin(-A)  (where  -A  is  equal  to  the  array  A with  each 
element  negated ),  this  is  equivalent  to: 
assert  -/ItO]  » /n/n(-/l[n;2n]) 

Thus,  the  transformation  "A  becomes  -A"  transforms  the  given  specification  into  the 
desired. 

Applying  this  transformation  to  the  program  affects  only  the  conditional  assignment: 

A[y-  ']*-if  AlZy-1  ] S A[2y]  then  A[2y-1]  else  A[2y]  fi  , 

which  becomes: 


-A[y-1  if  -A[2y-1  ]<  -A[2y}  then  -/l[2y-l]  else  -/l[2y]  fi 
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It  is  "illegal"  for  the  array  -A  to  appear  on  the  left-hand  side  of  an  assignment; 
therefore,  both  sides  of  the  assignment  are  multiplied  by  -I  . And  since  the  test 
-A[  2y-l  ] < -A[  2y]  is  equivalent  to  A[2y  ] < A[  2y-l  ] , we  obtain  the  statement: 

A[y-1'\»- if  A[  2y]  < 4[2y-I  ] then  4[2y-7]  else  A[2y]  fi  , 
yielding  a program  that  computes  the  maximum.  Note  that  the  array  -A  no  longer 
appears  in  the  program;  only  the  original  A is  actually  used. 


2.  Special  Case;  Program  Debugging 

Program  debugging  may  be  considered  as  a special  case  of  modification:  a program  which 
computes  wrong  results  must  be  modified  to  compute  the  desired  (correct)  results.  If  we 
know  what  the  "bad"  program  actually  docs,  then  wo  may  compare  that  with  the 
specifications  of  what  it  should  do,  and  modify  (debug)  the  incorrect  program 
accordingly. 

As  an  example,  consider  a program  Intended  to  compute  the  integer  square-root  z of  the 
non-negative  integer  c , that  is,  c should  lie  between  the  squares  of  the  integers  z and 
Z*1  I 

assert  s c < z i N , 


where  N Is  the  set  of  natural  numbers.  The  given  program  is; 
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{7.,  s,  o ♦ (?,  0.  3) 
loop  until  c < s 

(7,  5.  / ) • ( 2+  J . < + 2) 

repeat 

assert  {z- 1 )^  < c-*- 1 < 7/,  z i N* 

But  rathrr  than  computing  the  integer  square-root  of  c,  this  program  achieves  the 
relation: 

assert  {z- 1 )^  < c*  1 <2^,  z ( 

where  N*  is  the  set  of  positive  integers.  [ This  follows  from  the  fact  that  t=2z+l  and 

5 ' z^~l  throughout.]  The  cause  of  the  bug  was  the  inadvertent  exchange  of  the  initial 
values  of  z and  s . 


Comparing  the  desired  assertion  with  the  actual  assertion,  we  note  that  the  former  may 
be  obtained  from  the  latter  by  replacing  z with  z*l  and  c with  c-J  . Applying  the 
transformation  " c becomes  c-J  " to  the  program  statements  affects  only  the  exit  test 
c < s , which  becomes  c-J  < s . or  equivalently  css.  The  transformation  " z becomes 
z*l  " affects  two  other  statements:  the  initialization  z*-  1 becomes  z+J  •-  J and  the 
loop-body  assignment  z*  z*l  becomes  z*l>-z*2.  These  resultant  a.ssigninents, 
however,  are  "illegal",  inasmuch  as  an  expression  may  not  appear  on  the  left  hand  side  of 
an  assignment.  Instead,  the  expression  z*l  is  given  the  initial  value  J by  assigning 
z*-0,  and  the  value  of  the  expression  z*l  is  incremented  to  z+2  by  the  "legal" 
assignment  z>-  z*l  . 


i 


We  have  thus  obtained  the  corrected  program: 
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(z.  s.  0 - (0.  0.  3) 
loop  until  c < 5 

(z,  s,  t)  •-  {z+1,  s+t,  t+2) 
repeat 

assert  i c < (z+1  )^,  z i N . 


Note  that  though  this  program  Is  not  exactly  what  the  programmer  Intended  — we 
claimed  that  he  reversed  the  initial  values  of  z and  s — it  is  nevertheless  correct. 


3.  Correctness  Considerations 

In  the  above  examples,  the  transformed  programs  were  correct,  i.e.,  they  did  in  fact 
satisfy  the  transformed  specifications.  This  is  not  necessarily  the  case  with  any 
transformation.  Suppose,  for  example,  that  we  are  given  the  program: 

(z,  y)-  (A[0],  0) 
loop  until  y • n 
y-y+1 

z •-  min(z,A[y'i) 

repeat 

assert  z • min(A[0:n]) 

for  finding  the  minimum  of  the  array  i4[0:n] , and  we  wish  to  construct  a program  to 
find  the  maximum  of  the  non-empty  array  A[l;n].  The  given  program  achieves 
z - mfn(/l[0.’/i] , and  the  output  specification  of  the  desired  program  is 
z ~ max(A[  1 in]).  Thus,  the  transformations  " m/n  becomes  max  " and  " 0 becomes  1 " 
suggest  themselves.  Though  in  this  case  applying  these  transformations  happens  to  yield 
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a corrrct  program,  such  ti ansformations  of  a function  symbol  or  constant  do  not 
necessarily  preserve  correctness.  Were  the  function  nun  not  explicitly  used  in  the 
prog.ram,  e.g.,  il  the  conditional  stdlement: 

if  A[y]<z  then  z-/l[y]  fi 
were  substituted  for  the  assig,nment: 

Z‘  min(z,A[  y ]) 

then  the  proposed  transformation  " min  becomes  max  " would  clearly  not  work. 

It  can  be  shown  that  global  transformations  where  an  input  variable  is  systematically 
replaced  by  a function  of  input  variables,  or  an  output  variable  by  a function  of  output 
variables  — a.s  m the  previous  examples  — always  yield  a program  satisfying,  the 
transformed  specifications.  However,  ti ansformations  of  function,  predicate  or  const. int 
symbols  — as  in  this  last  example  — are  not  guaranteed  to  result  in  a program  satisfying 
the  specifications. 

Hence,  for  some  transformations,  correctness  must  bo  verified.  In  order  to  prove  the 
correctness  of  a program,  invariant  assertions  are  commonly  utilized.  Assertions  are 
comments  which  express  relationships  between  the  different  variables  manipulated  by 
the  program;  they  relate  to  specific  points  in  the  program,  and  are  meant  to  hold  for  the 
^ ^ current  values  of  the  variables  whenever  control  passes  through  the  corresponding 

i 

point.  When  an  a.s.sertion  has  been  proved  to  be  consistent  with  the  code  — j.e.,  the 
_ assertion  holds  for  the  current  values  of  the  variables  each  time  control  pa.s.ses  through 

the  point  to  which  the  assertion  is  affixed  — then  it  is  said  to  be  invariant.  [All 

; i.  ■ 

I 

* 

*> 

I P: 


d.ssertions  annotating  our  example  programs  are  indeed  invariant.]  In  particular,  the 
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output  assertion,  associated  with  the  point  of  termination,  is  invariant  if  the  final  values 
of  Jhe  variables  satisfy  the  assertion;  a loop  ass'^rtion,  attached  to  the  beginning  of  an 
Iterative  loop,  is  invariant  if  it  holds  when  the  loop  is  first  entered,  and  remains  true 
each  subsequent  time  control  passes  the  beginning  of  the  loop-body.  The  assertion  is 
termed  an  output  invariant  in  the  former  case,  and  a loop  invariant  in  the  latter.  A 
program,  then,  may  be  considered  correct  if  the  output  invariant  implies  that  the  output 
specification  is  true. 

Recently,  invariant  generation  techniques  have  been  developed  and  Implemented  (see, 
e.g.,  German  and  Wegbreit  [1976]  and  Katz  and  Manna  [1976]).  They  allow  for  the 
automatic  discovery  of  invariants  which  may  then  be  used  to  prove  the  correctness  or 
Incorrectness  of  the  program.  Invariant  assertions  are  essential  in  our  approach  to 
debugging  too,  as  it  is  necessary  to  have  an  idea  of  what  the  program  actually  does  before 
it  can  be  corrected. 

Global  transformations  are  applied  to  all  assertions,  as  well  as  to  the  code.  Using  these 
transformed  assertions,  verification  conditions  for  the  new  program  may  be  obtained;  if 
they  hold,  then  the  new  program  is  correct.  Sometimes,  a verification  condition  that 
turns  out  not  to  hold  may,  nevertheless,  suggest  additional  transformations  which  do 
succeed.  Alternatively,  a program  segment  can  be  synthesized  that  will  establish  the 
verification  condition;  for  example,  the  initialization  of  a loop  might  be  synthesized  if 
the  condition  for  the  current  Initialization  is  false. 


Returning  to  the  above  min  example,  the  program  with  its  loop  assertion  appended,  is: 
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(z.  y)  ^ (/1[0].  0) 
loop  assert  z^min{A[0:y]) 
until  y n 

y » y-^; 

z - nun{z,A[y]) 

repeat 

assert  z « /nin( /![  0;/i  ] ) 

After  application  of  the  transformations  " min  becomes  max  " and  " 0 becomes  1 ",  we 
obtain: 


(z,  y)  . (/U  f ].  1) 
loop  assert  z = max{A[  1 :y]) 
until  y « n 
y-y*] 

z •-  max{z,AlyJ) 

repeat 

assert  z = max(/l[  1 .n  ] ) . 

Using  the  new  assertions,  the  correctness  of  this  max  program  may  straightforwardly 
be  Shown. 


4.  i4n  Application:  Instantiation  of  Program  Schemata 

One  important  application  of  our  program  modification  techniques  is  the  instantiation  of 
program  schemata  to  obtain  concrete  programs.  A program  schema  is  a generalized 
version  of  some  programming  strategy  and  contains  abstract  predicate,  function  and 
constant  symbols,  in  terms  of  which  its  input-output  relation  is  specified.  This  abstract 
specification  may  then  be  matched  with  a given  concrete  specification  and  an 
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instantiation  found  that,  when  applied  to  the  schema,  yields  the  desired  concrete 
program.  Not  all  instantiations  yield  correct  programs;  therefore,  a schema  is 
accompanied  by  a set  of  preconditions  — derived  from  the  schema's  verification 
conditions  — which  must  bo  fulfilled  before  the  schema  may  be  employed.  When 
satisfied,  these  conditions  will  guarantee  the  correctness  of  the  new  program. 


As  an  illustration,  consider  the  following  program  schema: 

(z,  y)  - (A.  J) 

loop  assert  P([7.y].z),  yc  I 
until  y - n 
y-y+l 

If  -'P(y,z)  then  z>-f(y,z)  fi 

repeat 

assert  P([J:n],z) 

Here  P([u;v],w)  means  (Vi  ( I)(u  < i < v)(P(i,w))  and  I is  the  set  of  integers.  This 
schema  will  achieve  the  relation  P(i,z)  for  each  integer  i from  J to  n . 


For  this  schema  to  be  applicable,  the  following  three  preconditions  must  be  satisfied  by 
the  predicate  P , function  f and  constants  J , k and  n : 

P(J,k)  Ji  I 

P(\.J:y'\,t)  f'  y<i  A y-n  a ^P(yn,z)  =»  P([J:y*i],f(y-n,z)) 

J s n n f.  I . 

The  first  condition  ensures  that  the  loop  invariant  is  initialized  properly;  the  second  is 
sufficient  to  guarantee  that  if  the  invariant  held  before  execution  of  the  loop-body,  then 
it  holds  after;  and  the  last  condition  secures  termination. 
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I’rograms  lor  finding  the  position  or  value  of  tlie  niinimum/niaximum  of  an  array  (or  of 
other  functions  with  integer  domain,  for  that  matter)  are  valid  instantiations  of  this 
schema.  For  example,  say  we  wish  to  achieve  the  output  specification  /l[0.n]  r x , in 
order  to  find  the  maximum  x of  the  non-empty  array  A[0;n],  Applying  our 
modification  technique,  we  compare  i4[0;/i]<x  with  the  schema's  specification 
P([j:/i],z).  This  suggests  letting  j be  0 , z be  x and  P(u,v)  be  /l(u]<v.  The 
transformed  preconditions,  then,  are: 

/1[  0]  s ft  A o\  I 

A[0.y]'x  A ytl  a y»/i  a x</l[y+J]  =»  A[0:y-H  ] < f{y*  1 ,x) 

O < n n i I 

Tfie  first  may  l>e  achieved  by  letting  k be  /1[0]:  the  second  by  letting  f(u,v)  be 
i4[u],  since  A[0:y]<x<A[y*l]  and  A[yH  ] < A[y*  1 ] -,  the  last  is  true  by  virtue  of 
i4[  O.n]  being  non-empty. 

Applying  these  transformations,  viz. 
j becomes  0, 

k becomes  A[0], 

z becomes  x, 

f(u,v)  becomes  A[u] 
and  P(u,v)  becomes  /l[u]sv, 
we  obtain  the  guaranteed  correct  program: 
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(X.  y)  - (4[0],  0) 
loop  assert  i4[0;y]<x,  yc  I 
until  y * /} 
y-  y+1 

if  x<i4[y]  then  x*-/l[y]  fi 
repeat 

assert  i4[0:n]<x 


The  compilation  of  a handbook  of  such  schemata  has  recently  been  advocated  by  Gerhart 
[ 1975];  their  use  in  the  context  of  program  synthesis  has  been  discussed  by  Dershowitz 
and  Manna  [ 1975]. 


6.  Using  Extension 

Sometimes,  transforming  a program  or  instantiating  a schema  only  achieves  some  of  the 
conjuncts  of  the  output  specification.  In  such  a case,  it  may  be  possible  to  extend  the 
program  to  achieve  all  the  desired  conjuncts  by  achieving  the  missing  conjuncts  at  the 
onset  and  maintaining  them  invariant  until  the  end.  Alternatively,  code  that  will 
achieve  the  additional  conjuncts  — without  "clobbering"  what  has  already  been 
achieved  by  the  program  — could  be  synthesized  and  appended  at  the  end. 

As  an  example  of  the  need  tor  extension,  consider  the  case  where  it  is  desired  that  the 
program  above  also  find  the  position  z , in  the  array,  of  the  maximum  x . We  can 
extend  the  above  program  to  achieve  x>/l[z]  by  maintaining  that  relation  as  an 
Invariant  throughout  the  execution  of  the  program.  Initially  we  want  x • A[0}  • A[  z]  , 
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so  we  set  z •-  0 . When  the  then  path  is  executed,  we  want  x A[y]  • A[z]  and  assign 
z - y : when  that  path  is  not  taken,  x is  unchanged  and  the  relation  remains  true. 
Thus,  when  the  program  terminates,  the  desired  relation  x ^ A[z}  will  hold. 


The  extended  program  is: 

(X.  y.  z)  - (/l[0].  0.  0) 
loop  assert  i4[0.y]<x,  yt  /,  x-/l[z] 
until  y » /) 
y-y-n 

if  X < 4[y]  then  (x,  z)*-(/l[y],  y)  fi 
repeat 

assert  /l(0;/i]<x.  x-/l[z] 
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III.  EXAMPLES 

In  this  section  we  demonstrate  various  stages  in  the  evolution  of  one  program.  We  begin 
with  a program  containing  a logical  error  and  then  find  and  apply  alternative 
corrections.  An  abstract  version,  which  represents  an  important  search  method 
embedded  in  the  program,  is  then  applied  and  adapted  to  two  other  problems.  Each,  in 
turn,  is  modified  to  apply  to  a new  tasK. 

The  examples  are  outlined  in  Figure  1.  They  owe  their  motivation  to  Wensley  [ 1959] 
and  Dijkstra  [1976].  Our  modification  system  has  successfully  performed  the 
modification  steps,  including  debugging  and  instantiation,  in  these  examples  (sometimes 
resorting  to  the  u.ser's  expertise  in  theorem  proving).  An  annotated  trace  of  the  first 
example  may  be  found  in  the  Appendix. 


Example  1 : Bad  Beal  Division  to  Good  Beal  Division 

« 

Consider  the  problem  of  computing  the  quotient  z of  two  real  numbers  a and  b , where 
0 s a < b , within  a specified  tolerance  e , 0 < e . In  other  words,  the  input  specification 
is: 

O s a < b A 0 < e, 
and  the  output  specification  is: 
z s a/b  A a/b  < z*e, 
or  equivalently: 


b’zsa  A a<b’{z*e). 
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In  order  for  the  problem  to  be  non-trivial,  we  must  assume  that  no  general  real  division 
operator  is  available  (though  division  by  two  is  permissible).  The  given  program  Is: 

BAD  REAL  DIVISION  PROGRAM 


assert  0 < a < b,  0 < e 
(z,  y)-  (0,  I) 
loop  until  y i e 

it  b-  (z*y)  < a then  z«-z+y  fi 

y-y/2 

repeat 

— 

The  Initial  assertion  contains  the  input  specification  which  the  input  variables  a , b 
and  e are  assumed  to  satisfy.  But,  for  example,  a - 7 , b-3,  and  e-  1/3,  which 
satisfy  the  input  specification,  yield  z ■ 0 which  does  not  satisfy  the  second  conjunct  of 
the  output  specification.  The  bug  is  caused  by  the  interchanging  of  the  two  statements 
within  the  loop. 

Before  we  can  debug  this  program,  we  must  Know  more  about  what  it  actually  does.  For 
this  purpose,  we  annotate  the  program  with  loop  and  output  invariants.  Recall  that  for  a 
relation  to  be  a loop  Invariant,  it  must  be  true  upon  initial  entry  into  the  loop,  and  must 
remain  true  after  each  execution  of  the  loop-body. 

We  begin  with  the  then  path  of  the  conditional  statement  and  note  that  this  path  is 
taken  when  b-  (z*y)  s a ; thus,  after  resetting  z to  z*y  we  have  b-z<a.  Since 
b-zi  a is  true  initially,  when  z > 0 s a , and  is  unaffected  when  the  conditional  test  is 
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false  (the  value  of  z is  not  changed),  it  remains  invariant  throughout  loop  execution. 
We  have  derived  then  the  loop  invariant: 

( 1 ) t>-  z < 3. 

The  then  path  is  not  taken  tvhen  a < h-  { z+y ) . In  that  case  y is  divided  in  half  and  z is 
left  unchanged,  yielding  a < b-  (z-Hiy)  at  the  end  of  the  current  iteration.  It  turns  out 
that  the  then  path  pre.serves  this  relation  (the  value  of  z+Zy  is  unchanged),  and  that  it 
holds  upon  initialization  (since  a < Zb  is  implied  by  0 < a < 5 ).  Thus  we  have  the 
additional  invariant: 

(2)  a<b^^z■^Zy). 

These  two  loop  invariants  along  with  the  exit  relation  yse  imply  that  upon 
termination  of  the  program  the  following  output  invariants  hold: 
b- z < a A a<b-(z*Ze). 

Note  that  the  desired  relation  a<b-(z*e)  is  not  implied. 

The  annotated  program  — with  invariants  that  correctly  express  what  the  program  does 
do  — is: 
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ANNOTATED  BAD  REAL  DIVISION  PROGRAM 


assert  0 < a < b,  0 < e 
(z.  y)-  (0.  1) 

loop  assert  b-z<a,  a<b-{z*2y) 
until  y < e 

if  b-  (z*y)  < a then  z-z-t-y  fi 

y-  y/2 

repeat 

assert  b- z < a,  a<b-lz*2e) 


We  now  have  the  task  of  finding  a transformation  (correction)  that  transforms  the 
actual  output  assertion  into  the  desired  output  assertion-, 
assert  b- z < a,  a<b-(z+e)  , 

and  then  applying  it  to  the  whole  annotated  program  (statements  and  invariant 
assertions).  Accordingly,  we  would  like  to  modify  the  program  in  such  a manner  as  to 
transform  the  insufficiently  strong  a < b-  (z*2c)  into  the  desired  a<  b-  (z^e)  : 
a<b-{z*2e)  becomes  a<b-(z+e). 

At  the  same  time,  we  must  preserve  the  correctness  of  the  other  conjunct  of  the 
specification: 

b- z < a unchanged. 


The  most  obvious  correction  is  to  replace  all  occurrences  of  e in  the  program  ( there  is 
only  one  affected  statement  - the  exit  test  y s e ) with  e/2  : 

Correction  1 


Beptace  the  exit  test  y s e by  y s e/2  . 
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Additional  dphugging  modifications  are  po.s.siMe:  we  may  replace  b with  b/2  and  z 
with  Zz alternatively,  we  niiy.ht  replace  a with  Za  and  z with  Zz  . Doubling  z and 
either  halving  6 or  doubling  a in  the  conditional  test  b-{z*y)<a  yields  a test 
equivaleiu  to  b-(z*y/Z)<a.  Tr.iiisforming  z into  Zz  affects  two  additional 
statements:  the  initialization  z*  0 becomes  the  "illegal"  assignment  2z  •- 0 , but  the 
equivalent  original  assignment  z«  0 may  be  substituted;  the  assignment  z •- z+y  of  the 
then  branch  becomes  Zz-Zz-fy,  or  z>-z^y/Z.  No  other  statements  are  affected  by 
either  of  the  two  modifications;  thus  they  both  yield: 

Correction  2 

r 

lleplacc  the  conditional  statement  with 

if  b-  (z+y/2)  < a then  z •-  z+y/Z  ft  . 


Each  of  these  possible  transformations  involved  one  of  the  input  variables  e,  a and  b. 
One  must,  however,  be  careful  when  transforming  input  variables,  since  the 
transformation  should  be  aj>plied  to  the  input  assertion  as  well,  possibly  changing  the 
range  of  legal  inputs  thereby.  In  this  case,  the  transformations  we  have  performed  are 
all  permissible:  The  specification  0<e  is  equivalent  to  0 < e/2  and  therefore  halving  e 
has  no  effect  on  the  input  range.  Since  in  fact  the  condition  a < Zb  , rather  than  a < b , is 
strong  enough  to  imply  the  loop  iiivariaiils,  replacing  b by  b/2  (or  a by  2a  ) still 
yields  a program  correct  for  inputs  satisfying  a < b , as  is  desired. 

« 


Our  program  after  correction  2,  annotated  with  appropriately  modified  invariant 
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assertions  is  (all  b have  been  replaced  by  b/Z  and  all  z by  Zz  and  the  resultant 
expressions  have  been  simplified): 


assert  0 < a < b,  0 < e 

(z.  y)  - (0.  1) 

loop  assert  b-z<a,  a<b-(z+y) 
until  y < e 

if  b’(z*y/Z)<a  then  z>-z+y/Z  ti 
y - y/2 

repeat 

assert  b- z < a,  a<b-{z*e) 


This  program  may  be  slightly  optimized,  by  evaluating  the  subexpression  y/Z  before 
the  conditional  statement,  to  obtain: 

GOOD  REAL  DIVISION  PROGRAM 


assert  0 < a < b,  0 < e 
(z.  y)-  (0.  I) 

loop  assert  b- z s a,  a<b-(z*y) 
until  y < e 
y-y/2 

if  b-  (z+y)  s a then  z *-  z*y  fi 
repeat 

assert  b-z<a,  a<b-[z*e) 


Note  that  this  program  is  the  same  as  the  original  bad  program,  with  the  two  loop-body 


statements  commuted. 
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Example  Good  Heal  Division  to  Binary  Search  Schema 

f 

Considrr  an  abstract  version  of  the  correct  real  division  program  which  has  just  hren 
obtained: 

BINARY  SEARCH  SCHEMA 

(r..  y)  - (j,  k) 
loop  assert  /’(z),  C?(z+y) 
until  /<(y) 

y - y/^ 

if  P(z+y)  then  z<- z*y  fi 
repeat 

assert  P{z),  Q(z*e) 


This  schema  is  an  attempt  to  capture  the  technique  of  binary  search  underlying  the  real 
division  program.  It  is  obtained  from  that  program  by  abstracting  predicates  that  appear 
in  the  program  text  and/or  a.s.sertions: 
b- u < a becomes 

a < b- u becomes  0(u) 

and  use  becomes  B(u). 

The  initial  values  of  the  variables  are  also  abstracted: 

0 becomes  J 
and  1 becomes  k. 

The  following  four  preconditions  on  the  predicates  P,  Q and  B and  constants  J and  k 
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are  sufficient  to  guarantee  correctness  (they  correspond  to  the  verification  conditions  of 
( 1 ) the  initialization  path,  (2)  the  loop-hody  path  and  (3)  the  loop-exit  path,  and  (d) 
termination ): 

PRECONDITIONS  for  BINARY  SEARCH  SCHEMA 

(7)  r{j)  A Q(j*k) 

(2)  -P(z*y/2)  ^ Q{z*y/2) 

(3)  Q{z*y)  A P{y)  3 C(2+c) 

(4)  (3m)(/?Uc/2"’))  . 1 


What  we  have,  then,  is  a general  program  schema  for  a binary  search  within  a tolerance 
with  an  output  specification: 

P(z)  A Q{z*e). 

Clearly,  the  predicates  P and  R which  appear  in  the  schema  must  be  primitive  (that  is, 
available  in  the  target  language),  otherwise  they  must  be  replaced  by  equivalent 
predicates  for  the  schema  to  yield  an  executable  program.  Similarly,  the  constants  j and 
k must  be  given,  or  their  values  determined,  prior  to  their  assignment  to  the  variables 
z and  y . 


Example  3t  Binary  Search  Schema  to  Real  Square-root 


As  indicated  earlier,  one  of  the  applications  of  our  modification  system  is  the 
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instantiation  and  adaptation  of  program  schemata  to  specific  problems.  To  illustrate  how 
the  binary  search  schema  that  we  have  just  seen  may  be  used,  we  consider  the 
computation  of  square-roots. 

Suppose  that  we  are  given  the  task  of  constructing  a program  that  finds  the  square-root 
z of  the  real  number  c , 1 < c , within  the  tolerance  d , 0 < d . The  input  specification 

IS: 

0 < d A 1 < c, 

and  the  output  specification  is: 

Vc  < z A z-d  < Vc, 

that  IS,  the  result  z may  only  be  greater  than  the  square-root  of  c by  less  than  the 
given  d . 


In  order  to  match  this  output  specification  with  that  of  our  schema: 
r(z)  A 0{z+e), 

we  let  the  constant  e be  the  constant  expression  -d  (viewing  z-d  as  z*{-d)  ) and 
obtain  the  transformations: 

P{u)  hvcomes  Vc  < u, 

0(u*  becomes  u < Vc 

and  e becomes  -d. 


Condition  (2)  is  satisfied: 

(2)  -'(>/c  < z*y/2)  =>  z*y/2<-Jc, 

but  we  must  still  satisfy  i ions  ( 1 ),  (3)  and  (4).  To  satisfy  condition  ( 1 ),  we  need 


J and  k such  that; 
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( 1 ) Vc  < j j*k  < Vc. 

We  note  that  since  1 < c , we  have  Vc  < c and  c+(  7-c)  - 7 < Vc  . Thus  both  conjuncts 
hold  when  we  let: 

J be  c 
and  k be  7-c. 

[ An  alternative  would  have  been  to  take  -c  for  7c  , since  c+( -c)  » 0 < Vc  . ] 

For  condition  (3)  to  be  satisfied,  we  need  a predicate  /?  such  that: 

(3)  z*y  < Vc  A R(y)  =»  z-d  < Vc. 

By  transitivity  it  follows  that  R should  imply  z-d  < z*y  and  we  let: 

R(y)  be  -d  < y. 

This  also  satisfies: 

(4)  {2m){-d<  (l-c)/Z^), 
since  -d  is  negative. 


The  instantiated  schema  is: 

assert  0 < d,  1 < c 
(z,  y)  ^ (c,  7-c) 
loop  assert  Vc  < z,  z*y  < Vc 
until  -d  i y 

y - y/2 

if  Vc  < z+y  then  z-z*y  fi 
repeat 

assert  Vc  < z,  z-d  < Vc  . 


However,  since  P involves  the  square-root  function  itself,  the  conditional  test  is  not 
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primilivf  and  must  l>f  replaced.  It  can  lie  reidaced  by  c<  (z+y)^  provided  that  c and 
z*y  are  non-negative.  Ihcielation  Osc  follows  from  the  input  specification.  And  the 
relation  0 < z + .v  is  in  fact  an  invariant:  initially  z+y  « c+(  J-c)  « 1 ; for  the  then  path, 
y IS  first  halved  and  then  added  to  z , so  the  valve  of  z+y  is  unchanged;  and  if  the  then 
path  IS  not  taken,  y is  increased  by  halving  it,  since  y is  always  negative  (by  virtue  of 
the  loop  assertion  z*y  < Vc  < z ).  Tfius  we  have: 

« 


I 


[ We  remark  that  the  negative  y makes  this  program  appear  somewhat  unduly 
complicated;  replacing  y with  -y  throughout  the  program  would  alleviate  this.  ] 


REAL  SQUARE-ROOT  PROGRAM 


assert  0 < rf.  1 < c 
(z,  y ) - (c,  J-c) 

loop  assert  Vc  < z,  z*y  < Vc,  0 C z*y 
until  -d  < y 

y‘  y/2 

if  c<(z'^y)^  then  z<-  z*y  fi 
repeat 

assert  Vc  < z,  z-d  < Vc  . 


Example  4:  Heal  Square-root  to  Array  Search 

In  this  example,  we  demonstrate  how  the  above  square-root  program  may  be  modified  to 
obtain  a program  that  searches  lor  the  position  z of  an  element  b in  an  array  A[  1 ;/i] 
that  is  sorted  in  ascending  order. 


I 
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We  begin  by  comparing  the  output  specifications  of  the  desired  program  with  those  of 
the  given  program.  We  want  z ’=  poslA.b)  , where  pos{A,b)  is  the  po.sition  of  the 
element  b in  the  array  A . The  function  pos  is  the  inverse  of  the  array  indexing 
function,  j.e..  if  z ■=  pos(/l,b)  , then  h'i4[z].  We  shall  allow  indexing  the  array  by  real 
numbers,  in  which  case  the  array  element  intended  by  >l[u]  is  found  by  truncating  u 
to  an  integer.  It  is  therefore  sufficient  if: 

/>os(/l,b)  < z A z < pos(A,b)-H . 

[For  simplicity  we  a.ssume  that  b appears  exactly  once  in  A[ltn],  Nevertheless,  the 
program  we  derive  is  correct  in  the  more  general  case  where  the  number  of  occurrences 
of  b is  unspecified;  in  that  case,  pos  is  extended  to  yield  the  (possibly  empty)  set  of 
positionsof  b and  zc  pos{A,b)  is  desired.] 

For  the  square-root  program  we  had: 

Vc  < z A z-d  < Vc. 

Comparing  the  first  conjuncts  suggests  the  transformation: 

Vc  becomes  pos{A,b); 
to  obtain  this,  we  can  use: 

c becomes  pos{A,b)^. 

Applying  this  transformation  to  the  second  conjunct  of  the  square-root  specification 
yields  z-d  < pos{A,b)  , while  we  desire  z < pos{A,b)*  1 , suggesting  the  additional 
transformation: 


d 


becomes 


7. 


Page  28 


The  EvcVution  of  Programs 


Applying  these  tr.insform.iUons  to  the  sf)U<iie-rnot  program,  the  exit  test  -d  < y becomes 
- 7 I y . The  conditional  tost  cr(z*yY  bocoincs  pos(  A.b  ( z+y  )^  , which  is 
equivalent  to  pos(A,b)  < z+y  (since  both  /n>s(/l,b)  and  z+y  are  non-negative).  This 
contains  the  non-priniitive  function  pos  , Inil  we  can  test  b<  A[z+y]  instead  (since  A 
is  sorted).  Thus,  w’e  have  the  translormcd  program; 

(-’.  y)‘  {pns{A,b)^,  I-pos{A,b)^) 
loop  assert  pos(/l.b)  < z,  z+y  < pos[A,b),  0 < z-fy 
until  - 7 < y 
y - y/2 

if  6 s /1(  z+yj  then  z <-  z+y  fi 
repeat 

assert  pos(/l.b)  < z.  z<  pos{A,b)*l 


It  is,  however,  clearly  unsati.sfactory,  since  expressions  involving  pos  appear  in  the 
initialization.  Furthermore,  applying  the  transformation  to  c in  the  input  a.ssertion 

7 < c of  the  square-root  program  yields  7 < pos{A,b)^  which  does  not  hold  if 
pos(i4,b)  « 7 . The  loop  invariant,  though,  can  be  initialized  in  another  manner.  Since 
we  are  given  that  b appears  within  tfie  segment  A[  l-.n] , we  can  achieve  the  relation 
pos(/4,h)<z  by  initializing  z to  ri  , and  we  achieve  0 < z*y  < pos{A,b)  by  insisting 
that  z*y  • n*y  - 0 , for  which  we  initialize  y to  -n  . [Replacing  the  initialization  in 
general  requires  rechecRing  Uie  termination  condition;  in  this  case,  for  termination 

(3/n)(-7  s -n/Z^)  must  hold,  a.s  indeed  it  does.  ] 


We  have  obtained  the  program; 
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ARRAY  SEARCH  PROGRAM 


assert  sorterf(/l),  be  A[7:/i] 

(z,  y)>-  (n,  -ft) 

loop  assert  pos{A,b)  < z,  z*y  < pos(A,b),  0 < z*y 
until  -1  < y 

y - y/2 

if  b<4[z+y]  then  z •- z+y  fi 
repeat 

assert  pos{A,b)  < z,  z<pos{A,b)*l 


Example  6:  Binary  Search  Schema  to  Intefier  Square-root 


For  this  example  we  return  to  our  binary  search  schema: 
Preconditions; 


(1) 

P(j)  A 0(J>A) 

(2) 

^P(z*y/Z)  =» 

Q(z+y/2) 

(3) 

0(z+y)  A i?(y) 

=»  0(z+e 

(4) 

(3m)(/?(A/2^)) 

1 

Schema: 

(z,  y)  (J.  A) 
loop  assert  P(z),  O(Z'fy) 
until  B(y) 
y-y/2 

if  P(z*y)  then  z<-z*y  fi 
repeat 

assert  P{z),  Q{z*e)  , 
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and  llhistratp  how  it  may  ho  applied  to  the  computation  of  integer  square-roots.  Tins 
will  necessitate  extension  and  the  synthesis  of  an  initialization  loop  (which  have  not 
been  completely  implemented  in  our  system).  Consequently,  this  example  is  more 
complex  than  the  previous  one. 

We  W’ould  like  to  construct  a program  that  finds  the  integer  square-root  z of  a 
non-negative  Integer  c.  In  other  words,  z should  be  the  largest  integer  whose  square  is 
not  greater  than  c.  Thus,  the  input  specification  is: 
c ( N, 

and  the  output  specification  is: 

z^<c  /\  c < (z*  1 A z ( N. 

Comparison  of  this  output  specification  with  that  of  our  schema: 

P(z)  A C?(z+e), 
suggests  letting: 


P(u) 

be 

< 1 

Qiu) 

be 

c < u 

and 

e 

be 

1. 

In  addition,  we  will  have  to  ensure  that  the  final  value  of  z Is  a non-negative  Integer. 

Clearly,  condition  (2)  Is  satisfied: 

(2)  -((z+y/2)^<  c)  =»  c<{z+y/2f. 

To  satisfy: 

(3)  c<(z+y)^  A B{y)  =*  c<(z+f)^. 
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we  let: 

fl(y)  be  (z+y)^<  (z+J  )^. 

We  are  left  with  the  initialization  and  termination  conditions: 

( 1 ) j'^  < c A c < 

(4)  (3m)((z+/c/2^)^<  (z*n^). 

In  order  to  satisfy  the  initialization  condition  we  form  the  goal: 
achieve  j^ic,  c<  (J*k)^ 

This  conjunctive  goal  may  bo  split  into  two  consecutive  ones: 

achieve  < c 
achieve  c < (j*k)^ 

Since  c is  specified  to  be  non-negative,  we  can  solve  the  first  by  letting: 
J be  0. 

i.e.,  z is  initialized  to  0.  For  the  second  we  need  now  achieve  c < k^  . 


Our  partially  written  program  is: 
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assert  c ( N 
7.  • 0 

achieve  c < 
y - k 

loop  assert  7/ < c,  c<  {z-^y)"' 
until  ( 7*y  1 1 

y • y/2 

if  (z-fy)^'c  then  z>  z*y  fi 
repeat 

assert  7^  < c.  c < (z*l  )‘ 
achieve  z < N 

assert  < c.  c < (z*  1 )^ , z <.  N . 


At  this  point  we  have  a choice:  lu  order  to  achieve  z <.  N , either  we  first  execute  the 
loop  and  then  adjust  z to  satisfy  the  additional  goal  zc  N while  preserving  the 

relationships  z^  < c and  c (z+1)^  achieved  by  the  loop,  or  we  achieve  z < N first  and 
then  preserve  it  throughout  the  loop  coniputalion. 

The  extension  technique  suggests  preserving  z<  N throughout  loop  computation.  [This 
is,  in  fact,  the  more  efficient  of  the  two  choices.]  Initially  z^  Ot  N , but  since  z is 
sonietiines  incremented  by  y , the  latter  should  also  be  a non-negative  integer. 

Assuming  that  z and  y are  non-negative,  the  exit  test  (z^y)^  < (z+7  can  be  replaced 
by  y < 1 , Furthermore,  y is  non-zero  (since  at  the  start  of  the  loop  0 < Vc  < ft  « y and 
the  only  operator  applied  to  y is  halving),  so,  under  the  assumption  that  y is  an 
integer,  we  need  only  test  for  y • J . 

Finally,  In  order  for  y to  remain  in  N while  it  is  repeatedly  halved  until  it  equals  1 , 
we  must  have  y i z'^ . So  initially,  when  y - A , wc  Insist  that  k i z'^ , and  accordingly 
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add  the  conjunct  k < 2^  to  the  Initialization  subgoal  c < . Note  that  now,  with 

k i.  2^  , the  termination  condition: 

(4)  Om)({z*k/2"^)^  i (z+lf) 

clearly  holds. 


Thus  far,  we  have  the  partially  written  program: 

assert  c c N 

z •-  0 

achieve  c < k^,  k c 2'^ 
y •-  k 

loop  assert  z^  s c,  c < (z+y)^,  zt  N,  y i 2^ 
until  y ■ 1 
y-  y/2 

if  (z+y)^  sc  then  z*-z*y  fi 

repeat 

assert  z^  < c,  c < (z*l  )^,  z ( N . 


The  unachieved  subgoal: 

achieve  c < k^,  k c 2^ 

must  now  be  synthesized.  We  would  first  attempt  to  achieve  this  goal  one  conjunct  at  a 
time.  The  first  conjunct  might  be  achieved  by  letting  k - c+ 1 , while  the  second  could 
easily  be  achieved  by  letting  k • 1 . However,  though  each  conjunct  is  achievable  by 
Itsdlf  in  this  manner,  achieving  both  together  is  more  difficult,  since  these  two  solutions 
in  general  conflict  with  each  other. 
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So,  wp  transform  this  conjunctive  goal  into  an  iterative  loop,  choosing  first  to  achieve 
k i 2^  by  letting  k 2°  ~ 1 , and  then  to  keep  it  true  while  executing  the  loop  until  the 
remaining  conjunct,  c ^ k^  , is  also  satisfied.  Within  the  loop,  doubling  k with  each 
iteration  will  pre.serve  the  invariant  k c 2^  while  making  progress  towards  the  exit  test 
c < k^  . [The  reasoning  is  as  follows:  We  know  that  k should  be  Increasing,  since 

initially  k • 1 and  ultimately  we  want  0 < >/c  < k . Since  we  wish  k^  2^  for  some 
natural  number  n to  remain  invariant  while  k increases,  it  follows  that  the  exponent 
n also  increases.  Doubling  k increments  the  exponent  by  7.] 

We  have  olitained  the  following  initialization: 

assert  c i U 
(z,  *)-  (0,  7) 
loop  assert  k c 2^ 
until  c < k^ 
k>-2k 
repeat 

y *-  k 

Note  that  the  last  assignment  y •-  k is  superfluous;  it  may  be  eliminated  if  we  replace 
all  occurrences  of  k in  the  code  with  y . With  this  change,  we  have  the  integer 


square-root  program: 
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INTEGER  SQUARE-ROOT  PROGRAM 


assert  c c N 
(z.  y)  - (0.  I) 
loop  assert  y ( 2^ 
until  c < y^ 

y ‘ P-y 

repeat 

loop  assert  < c,  c < (z+y  )^,  z ( N,  y i 2^ 
until  y * I 

y ‘ y/2 

if  (z-*y)^<c  then  z •- z+y  fi 
repeat 

assert  z^  < c,  c < {z* 1 )^ , z ( N 


Example  6:  Intep.er  Square-root  to  Hardware  Integer  Division 

We  wish  to  construct  a program  to  compute  the  quotient  q and  remainder  r of  two 
natural  numbers  a and  b.  Such  a program  could  be  developed  from  our  binary  search 
schema  in  the  same  manner  as  we  constructed  the  integer  square-root  program.  But, 
Instead,  we  will  demonstrate  how  to  transform  the  just  constructed  integer  square-root 
program  directly  into  the  desired  integer  division  program. 

The  program  must  satisfy  the  output  specification: 

Osr  A r<b  A q(N  a a^b^q+r, 
or  equivalently: 

(•)  q s a/b  A a/b<q*l  q i N r-a-b-q. 
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given  the  input  specification: 
a i N A h i N* 

( N*  IS  tlie  set  of  positive  integers).  [H'  jihiaMiig  spC'Clf ications  — so  tfi.it  tfieir 
siniilanty  with  the  specifications  of  another  prop, ram  or  schema  can  he  brought  out  — is 
a non-tnvial  problem  in  us  own  right.  Our  system  only  finds  some  close  variations.  ] 

We  compare  tfie  output  specif  ication  ( ' ) wiiti  that  of  the  square-root  program.- 
7.^  < c A c '■  {z*  1 A z i.  N, 


or: 

^ < Vc  A -Jc  < z*\  A z i N, 
and  ol'tain  the  transforitiations: 
z becomes  q 

and  Vc  becomes  j/b. 

To  obtain  the  latter,  we  can  use: 

c becomes  (a/b)^, 

(since  a/b  is  non-negativc).  In  addition  we  will  have  to  achieve  r-a-b-q  . 


Applying  these  transformations,  the  exit  test  of  the  first  loop,  c < , becomes 

^ (a/b)^  • . Since  lioth  a/b  and  y arc  non-negativc,  this  is  the  same  as  a/b  < y or 

a < b- y . Similarly  tfie  conditional  test  ^.z^^y)^<c  becomes  [q*y)^  < (a/b)^  . or 
equivalently  b-  {q*y)  s a . 

Thus,  we  have  the  program: 


J 
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(q,  y)  •-  (o,  1) 
loop  assert  y ( 

until  a < b-y 
y - 2y 

repeat 

loop  assert  q < a/b,  a/b  < q*y,  q i N,  y i Z^ 
until  y * 7 

y - y/2 

if  b-  (q*y)  < a then  q •-  q*y  fi 
repeat 

assert  q < a/b,  a/b  < q*l , q t N 

Special  attention  must  be  paid  to  the  input  specification:  By  applying  the  transformation 

c becomes  {a/b)  to  the  input  assertion  of  the  integer  square-root  program,  the 
input  condition  for  this  program  is  obtained.  We  note,  however,  that  the  only  fact 
needed  for  the  construction  of  the  square-root  program  was  0 < c -,  its  input 
specification  c ( N was  unnecessarily  restrictive.  Applying  the  transformation  to  O < c 
yields  0<  (a/b)^  . Now,  since  this  is  Implied  by  the  input  specification  a t N /\  b i N* , 

the  above  program  is  correct  for  any  legal  values  of  a and  b . 

To  achieve  the  additional  output  specification  r - a-b-q  , we  extend  the  above  program 
to  Keep  that  relation  Invariantly  true.  So  whenever  q is  updated,  it  is  necessary  to 
update  r accordingly:  when  q is  Iniiialiaed  to  0,  r~a-b-0-a-,  when  q is 
incremented  to  q*y , r becomes  a-b-{q*y)^  r-b-y  . 

So  far  we  have: 


I 
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assert  a c N,  b i N* 

(q,  y,  r)  * {0,  1,  a) 

loop  assert  y c 2^,  r >=  a-b-q 
until  a < 6-  y 

y • 

repeat 

loop  assert  g < a/b,  a/b  < g+y.  q (.  N.  y i 2^,  r = a-b-  g 
until  y * 2 

y ► y/2. 

if  b-  (g+y)  < a then  (g,  r)  <-  (g+y,  fb-y)  fi 
repeat 

assert  g < a/b,  a/b  < q*l , g<  A2,  r - a-b-  g 


Note  that  the  conditional  test  b-(g-^y)<a  is  equivalent  to  b- y < a-b- g or  b- y < r . 
expression  b-  y involves  multiplication  and  appears  three  times,  so  a new  variable 
introduced  to  always  equal  b-y.  Substituting  u for  all  occurrences  of  b- y 
updating  u whenever  the  value  of  y is  changed,  we  obtain: 


The 
u is 
and 
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HARDWARE  INTEGER  DIVISION 


f 

assert  a ( N,  b { N* 

{q,  y,  r,  u)  •-  (0,  7,  a,  b) 
loop  assert  yc  2^,  r-a-b-q,  u-b-y 
until  a < u 
(y,  u)  ♦-  (2y,  Zu) 
t repeat 

loop  assert  q < a/b,  a/b  < g+y,  q < N,  y i 2^, 
r - a-b-  g,  u - b-  y 
until  y - 7 
(y,  u)  •-  (y/2,  u/2) 
if  u<r  then  (g,  r)*-(g+y,  r-u)  fi 
repeat 

assert  g < a/b,  a/b  < q*l , q i N,  r ^ a-b-  q . 


This  then  Is  the  desired  hardware  Integer  division  program.  Its  only  operations  are 
addition,  subtraction,  comparison  and  shifting,  all  of  which  are  hardware  instructions 
on  binary  computers. 

Note  the  similarity  between  the  extension  and  optimization  steps  in  this  example.  In 
both  cases  a relation  was  added  and  kept  invariantly  true  at  all  points  of  the  program. 
Most  of  the  previous  examples  would  have  profited  from  similar  optimizations. 
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APPENDIX 


The  following  i*;  a OLISP  tracp  of  Exainplf  1 (the  debugging  of  the  real  divi'tion 
program),  as  executed  by  our  modification  system.  The  steps  and  expressions  differ 
somewhat  from  the  example  as  presented  in  the  previous  section.  The  trace  has  l«'en 
edited  and  annotated  to  enhance  its  understandability.  False  leads  that  the  system 
followed  are  also  Included. 

The  procedure  MODIFY  modifies  a program  to  achieve  a new  goal.  Here  it  is  used  to  debug  a 
real  division  program 

MODIFY 

This  IS  the  annotated  given  bad  program: 

((ASSERT  (AND  (LTQ  0 A)  (LT  A (TIMES  2 B))  (LT  0 E))) 

(SETO  Z 0)  (SETO  Y 1) 

(LOOP  (ASSERT  (AND  (LTO  (TIMES  6 1)  A)  (LT  A (TIMES  6 (ADD  I (TIMES  2 Y)))))) 

(UNTIL  (LTO  Y E)) 

(If  (LTO  (TIMES  B (ADD  Z Y))  A)  THEN  (SETO  Z (ADD  Z Y))  FI) 

(SETO  Y (DIV2  Y)) 

REPEAT) 

(ASSERT  (AND  (LTO  Z (DIV  A B))  (LT  (OIV  A (TIMES  2 B))  (ADO  (DIV  Z 2)  E))))) 

prefaced  by  an  input  assertion,  containing  the  conditions  under  which  the  invariants  hold, 
and  followed  by  output  invariants.  We  desire  that  the  program  achieve  the  output 
specif ication 

(ASSERT  (AND  (LTO  Z (OIV  A B))  (LT  (DIV  A B)  (ADO  Z E)))) 

with  the  legal  inputs  defined  by  the  following  input  specif ication: 

(ASSERT  (AND  (LTO  0 A)  (LT  A B)  (LT  0 E))) 

Note  that  this  specification  differs  from  the  input  assertion  of  the  program 

The  system  begins  by  applying  the  function  MATCH  to  compare  the  output  invariant  with  the 
desired  output  specification: 

MATCH  (AND  (LTO  Z (DIV  A B))  (LT  (DIV  A (TIMES  2 B))  (ADO  (DIV  Z 2)  E))) 

(AND  (LTO  Z (DIV  A B))  (IT  (DIV  A B)  (ADD  Z E))) 

The  first  conjuncts  of  both  are  the  same,  and  the  system  compares  the  second  conjuncts  It 
notices  that  If  the  expression  (TIMES  2 B)  could  be  transformed  into  B and  (DIV  Z 2)  into 
Z.  then  the  whole  conjunct  would  transform  as  desired  So  it  calls  the  function  INVERT, 
Which  suggests  the  transformation  "B  becomes  (DIV  B 2)"  for  (TIMES  2 B): 

INVERT:  (TRANSFORM  (TIMES  2 B)  B) 
result*  (TRANSFORM  6 (DIV  B 2)) 
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and  similarly  for  (['IV  7 7) 

INVfKT  (fRANSfORM  (tUV  7 ?)  7) 
roMill  (IRAN.SfORM  7 (IIMtS  7 7)) 


Thus,  the  system  has  found  transf  ormat ion  i 


((TRANSIORM  B (PIV  P 7))  (TRANSfORM  7 (TIMfS  7 7))) 

But  first,  the  system  must  apo'y  this  transformation  to  the  first  conjunct' 

TRANMORM  fXPRS  (HO  7 (PIV  A B)) 
result:  (no  {TIMIs,  7 7)  (PIV  A ([lIV  B 7))) 

and  prove  that  the  conjunct  remains  true,  i.e  . 

(IMI’LltS  (no  (TlMfS  7 7)  (PiV  A (PIV  B ?))) 

(no  7 (PIV  A B))) 


Before  proceedin(|.  the  system  loots  for  additional  possible  transformations  Since  A[i[i  is 
commutative,  an  attempt  is  also  made  to  match  (A[i[i  ([liV  7 7)  E)  with  (A[ip  E 7)  This, 

together  with  (TRANSfORM  B ((i|V  B ?)).  yields  transformation  7: 

((TPANSfORM  B (PIV  B ?))  (TRANSfORM  £ 7)  (TRANSfORM  7 (TIMES  7 E))) 

However,  this  set  of  transformations  is  d is(|ua  1 1 f led . since  there  is  no  way  to  transform 
the  variable  7 into  the  constant  expression  (TIMES  7 E) 


Continuing  in  its  search  for  alternative  transformations,  the  system  also  finds  equivalent 
formulations  of  the  specifications,  e q ; 

(ANP  (LTQ  (TIMES  B 7)  A)  (IT  A (A(i(i  (TIMES  B 7)  (TIMES  7 B E)))) 

(ANP  (LTO  (TIMfS  B 7)  A)  (IT  A (APP  (TIMES  B 7)  (TIMES  B E)))) 

Comparing  them  yields  transformation  3 

((TRANSfORM  E (PIV  E ?))) 


The  system  now  carls  the  function  TRANSfORM  PROGRAM  for  each  of  the  two  eligible 
transformations  (1  and  3)  in  turn 


TRANSfORM  PROr'.RAM 

((ASSERT  (ANP  (ITO  0 A)  (LT  A (TIMES  7 B))  (LT  0 E))) 

(SETO  7 0)  (SEIO  Y 1) 

(LOOP  (ASSERT  (ANP  (LTO  (TIMES  B 7)  A)  (LT  A (TIMES  6 (APP  7 (TIMES  2 Y)))))) 

(UNTIt  (LTO  Y f )) 

(If  (ITO  (TIMfS  B (APP  7 Y))  A)  THEN  (SETQ  7 (APP  7 Y))  fl) 

(SETO  Y (PIV7  Y)) 

Rt  PEAT) 

(ASSERT  (ANP  (LIO  7 (PIV  A B))  (LT  (plV  A (TIMES  2 B))  (APP  (PIV  7 2)  E))))) 
((TRANSfORM  B (PIV  B 2))  (TRANSfORM  7 (TIMES  2 7))) 

TRANSfORM  CONST-EXPR.  which  transforms  constants,  is  now  called,  and  B is  replaced  by  (|i|V 
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B 2)  Ihroiiqhoul: 

TRANSFORM  CONST-tKPR  (TRANSFORM  B (PIV  B ?)) 

TRANSFORM  VAR  FXPR  transforms  a variable,  in  tins  case  the  variable  Z becomes  (TIMfS  2 Z): 
TRANSFORM  VAR- tXPR  (TRANSFORM  Z (TIMES  2 Z)) 

TFils  may  entail  eliminatinc)  expressions  from  the  left-hand  side  of  assignments.  The 
function  TRANSFORM-SETO  is  used  to  apply  (TRANSFORM  Z (TIMES  2 Z))  to  all  assignments  to  Z: 

(SETO  Z 0) 

result^  (SETO  Z (tUV  0 2)) 


and  : 


(SETO  z (Ann  z y)) 

resu1t=  (SETO  Z (DIV  (AdO  (TIMES  2 Z)  Y)  2)) 


The  transformed  program  is 

((ASSERT  (AND  (ITO  0 A)  (IT  A (TIMES  2 (EHV  6 2)))  (LT  0 E))) 

(SETO  Z (EHV  0 2))  (SETO  Y 1) 

(LOOP  (ASSERT  (AND  (LTO  (TIMES  (EHV  B 2)  (TIMES  2 Z))  A) 

(IT  A (TIMES  (HIV  B 2)  (AElO  (TIMES  2 Z)  (TIMES  2 Y)))))) 

(UNTIL  (LTO  Y E)^ 

' (IF  (ITO  (TIMES  (niV  6 2)  (And  (TIMES  2 Z)  Y))  A) 

THEN  (SETO  Z (dIV  (A(id  (TIMES  2 Z)  Y)  2))  FI) 

(SFTO  Y (dIV2  Y)) 

REPEAT) 

(ASSERT  (ANd  (LTO  (TIMES  2 Z)  (dIV  A (dIV  B 2))) 

(LT  (dIV  A (TIMES  2 (dlV  B 2)))  (Add  (dlV  (TIMES  2 Z)  2)  E))))) 

Non-executable  statements  (involving  dIV)  are  now  replaced  by  executable  ones  (dIV2)  as 
part  of  a simplification  step.  The  simplified  expressions  have  been  underscored;  they 
include  replacing  TIMES  by  T1MES2,  where  possible  Thus  the  system  obtains  its  f irst 
corrected  program 

((ASSERT  (ANd  (LTO  0 A)  (LT  A (TIMES  2 (dIV  B 2)))  (LT  0 £))) 

(SETO  Z 0)  (SETO  Y 1) 

(LOOP  (aTsERT  (ANd  (LTO  (TIMES  (dIV  B 2)  (TIMES  2 Z))  A) 

(LT  A (TIMES  (dlV  B 2)  (Add  (TIMES  2 Z)  (TIMES  2 Y)))))) 

(UNTIL  (LTO  Y E)) 

(If  (LTO  (TIMES  (dlV2  B)  (Add  (TIMES2  Z)  Y))  A) 

THEN  (SETO  Z TdTvZ  (Add  (TIMES2  Z)  Y)))  FI) 

(SETO  Y (dlV2  Y)) 

REPEAT) 

(ASSERT  (ANd  (LTO  (TIMES  2 Z)  (dIV  A (dlV  B 2))) 

(LT  (dIV  A (TIMES  2 (dlV  B 2)))  (ADO  (OIV  (TIMES  2 Z)  2)  E))))) 


Lastly,  it  must  be  proved  that  the  transformed  input  assertion  is  implied  by  the  given 
input  specification,  1 e 

(IMPLIES  (AND  (no  0 A)  (LT  A B)  (LT  0 E)) 

(ANd  (LTO  0 A)  (LT  A (TIMES  2 (dlV  B 2)))  (LT  0 E))) 
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and  il  docs,  since  (llMtS  2 (lilV  B 2))  is  equal  to  B. 


The  second  possible  Iransformal  ion.  Irunsformal ion  3.  is  now  applied; 

TRANSFORM- PROGRAM 

((ASSFRT  (AN(i  (no  0 A)  (LT  A (TIMES  2 B))  (LT  0 E))) 

(SETO  Z 0)  (SETO  Y 1) 

(LOOP  (ASSERT  (ANO  ( I TO  (T’MES  B Z)  A)  (LT  A (TIMES  B (AElD  Z (TIMES  2 Y)))))) 
(UNTIL  (LTO  Y E)) 

(If  (LTO  (TIMES  B (Add  Z Y))  A)  THEN  (SETO  Z (AdCl  Z Y))  FI) 

(SETO  Y (dlV2  Y)) 

REPEAT ) 

(ASSERT  (ANd  (LTO  Z (dIV  A B))  (LT  (dIV  A (TIMES  2 B))  (AOO  (OlV  Z 2)  £))))) 
((TRANSFORM  E (dIV  E 2))) 


oblaininq  (after  simplification)  a second  corrected  program: 


({ASSERT  (ANd  (LTO  0 A)  (IT  A (TIMES  2 B))  (LT  0 (DIV  E 2)))) 

(SETO  Z 0)  (SETO  Y 1) 

(LOOP  (ASSERT  (ANd  (ITO  (TIMES  B Z)  A)  (LT  A (TIMES  B (ADO  Z (TIMES  2 Y)))))) 

(UNTIL  (LTO  Y (EHV2  E))) 

(IF  (LTO  (TIMES  B (Add  Z Y))  A)  THEN  (SETQ  Z (ACid  Z Y))  FI) 

(Sf  TO  Y (dIV2  Y)) 

REPEAT) 

(ASSERT  (ANd  (LTO  Z (DIV  A B))  (LT  (CUV  A (TIMES  2 B))  (Add  (OiV  Z 2)  (CUV  E 2)))))) 

Aqain  It  must  be  shown  that  the  transformed  input  assertion  is  implied  by  the  input 

spec  if  ica t ion : 

(IMPLIES  (ANd  (LTO  0 A)  (LT  A B)  (LT  0 E)) 

(ANd  (LTO  0 A)  (LT  A (TIMES  2 B))  (LT  0 (OIV  E 2)))) 

which  IS  indeed  true,  since  A<2B  is  implied  by  A<B  and  0<E/2  is  equivalent  to  0<E. 


